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One does not have to sit in on discussions of architectural programming for very long before 
he realizes that the issue is a big one, a nut with many facets and aspects/ a nut which is 



going to be particularly difficult to crack. 



While it is possible to split and categorize the nut in many different wayS/ I should like to 
make a division of my own — for my own devices * That iS/ to divide the problem of archi- 
tectural programming into two primaiy but interrelated problem areas . 



The fiist problem area is that of NEEDS DEFINITION, the spelling out of what the client does, 
how ho does it, and what its environmental needs ond facility implications aroo This, of course/ 
forays into man and his needs, and results in explorations in sociology, psychology, physiology, 
and other human-oriented disciplines. It involves, too, a careful and sometimes minute dis- 
section of the client. This aspect of programming is tremendously significant and is currently 
receiving a great deal of very deserved emphasis, both in architecture and in the reloted fields 



mentioned. 
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I should like to address my remarks to a second probleui area, however; NEEDS DOCUMEN- 
TATION AND COMMUNICATION « This Involves the taking of the needs and implications 
derived above, collecting them, documenting them, and transmitting them to their ultimate 

V 

users o This is not entirely distinct from the area of needs definition — indeed, the way a 
need is defined will have a great deal to do with Its communication and use — but it does 
go a great deal farther than just deciding what words will be used, or what format will be 
employed. It begins to get at the very structure of the programming, programming/design, 
and design processes , 

0 

Today I would like to focus in on this particular part of die problem, expressing what I feel 
to be some of the fundamental issues, and presenting some work done at the Center for Archi- 
tectural Itesearch toward attacking those issues. I should soy at the outset that the fsttaek is 
necessarily along a limited front — not only is it aimed at a small part of the overall “pro- 
gramming problem “, but it also was undertaken os part of a very real program-developing 
lesaarch project for a very real client and with a very reol deadline! 



\ 

I What is a fundamental fault in our usual documentation and communication of needs? Simply 

I stated, we usually fall to recognize how o ur need — beoutifully researched and brilliontly 

; 

described — will be used by the architect or others working on the project. We foil to aredlet 
when it will be used, and in what form. We fail to recognize that the same piece of informa- 
tion may be used at many points in the project, each time in a different context, and each time 
requiring the statement of the need in a different form . 
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Veiy simply. It H possible to view the design process os the continuous taking or criteria of 
some sort, the development of solutions to fulfill the criterlo, the evaluation of solution a^rinst 
€■ Iterio, and the moking of necessary adjustments (In either solution or critericj to insure on oc- 

curate “fit‘'e 



The user does not go through this act once 
Rather he goes throu^ it agdrn and again: 



in a process of producing a single proiect (Figure l)o 
in making brood site and economic designs/ in do- 



Ing geneml concept work, in working with building oreos and rooms. In making decUlons about 
electrical outlets and doorknobs. "Criteria", therefore are used throughout the design process -- 
not just at one magic moment where the architect sits down and says, "Hand me the criteria. 



boys"l 



And yet this is precisely whet we have been doing. We get all the facts together, we collate 
organize, cotegorlze, and sometimes synthesize them into o single package colled the "build- 
ing program". Once it Is written, and the Introduction added by a famous man, we hand it 
over to the architect - "Here, fella, here's the criteria". 



To lepeot, the lather tiodlHonal building program fails to tecogrtlze thot these criterlo will be 
colled on at many doges in the progmmmlng/deslgn pwcesses, for o variety of ends, to be mani- 
pulated and used in a variety of ways. So on the one hand, when we speak of crIteHc and their 

fonnulotion, we must be conscious of the USE TO WHICH THEY WILL BE PUT - THEIR -DESTI- 
NATION" IF YOU WILL. 



On the other hand, however, we most also consider their ORIGIN —WHERE DO THEY COME 

FROM? Now It's obvious that many of those criteria ore already in the architect's mind, or 
In convenlenriy accessible places, os he desKps. Information on locations of doorknobs and 








A GeneroUzed Model of the Design Process 
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convenience ootleh often falls In the realm of "standards- - that Is, criteria which opply 
equally to the bulk of iobs rather thon specifically to a few job . Looking at those crrtena 
which are unique from job to lob, however (and I should soy that this body will vary from 
[ob to job, and from designer to designer - a criterion which it "obvious" in one instance 
will need to be carefully detailed in another), we hove to ask ourselves the question — 

where do they come from? 

The f h"rr«« are that they will be gathered by the usual technlquess interviewing, research, 
observation, literature search, etc. They will bo “cllent^oriented" — thot is, they will be 
in his language anti gathered within the framework of his orgonizotion. The chances o"e that 
the Information will be of widely varying degree of detail: some applying to the project os 
a whole, some applying only to speciftc portions of that project. 

THE PROBLEM, THEN, IS SIMPLE TO STATE; HOW DO WE GET FROM ORIGIN TO DES- 
TINATION? How do wo take all this Infarmatlon, client-oriented, collected from his people, 
often in hU language, and varying depths of detail and tom it Into architect-oriented infar- 
motion, in I* language, far hU use, and orierrted to the porticular use he^^wlll pot it to? 

Takq far example, a project we are currently completing. Here is a large regional education 

center In Northern Westchester, New York, which provides edocotional programs and services 

ID 13 public school dfetricts in thot oreo,* The clientk octivlties ran o wide gamut, including, 

programs far 450 emotionally-disturbed <md/ar broin injured 
children 

pragrotm far 150 mentally-retarded trainable children 
guidonce and testing far the half-county area 



•The project was undertaken far the Northern Westchester Board of Coope^lve Edu^ional 
Services, Yorktown Hei^ils, New York, and was fended by Edocotional Facilities Laboro- 

torioSf Inc o 
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convenience ooHeJs often foils in the realm of "stondai*" - that h. criteria which apply 
e<|ually to the bulk of |ob* rather than specifically to a fsw jobso Looking at those criteria 
which ore unique from job to job, however (and I should say that this body will vary from 
job to job, and from designer to designer - a criterion which is “obvious" in one instance 
will need to be carefiilly detailed in onother), we have to ask ourselves the question — 
where do they come from? 

The are thot they will be gathered by the usual techniques: interviewing, research, 

observation, literature search, etc. They will be "client-oriented" — that is, they will be 
in his language and gothered within the framework of his organisation. The chances are that 
the information will be of widely varying degree of detail: some applying to the project as 
a whole, some applying only to specific portions of that proiect. 

THE PROBLEM, THEN, IS SIMPLE TO STATE: HOW DO WE GET FROM ORIGIN TO DES- 
TINATION”? How do v» take ell this Information, client-oriented, collected from his people, 
often in hU language, and varying depths of detail and tom it into architect-oriented infor- 
mation, in 1^ languoge, for I* use, and oriented to the porticular use to will pot It to? 

Takq for exomple, a project we ore currently completing. Here Is o large regional education 

center in Northern Westchester, New York, which provides educotlonal programs and services 

to 13 public school districts In that oreo.* The clients activities ran o wide gamut, including, 

programs for 450 emotional ly-dbturbed and/or brain injured 
children 

programs for 150 mentally-retarded trainable children 
guidance and testing for the half-county area 



•The project was undertaken for the Northern Westchester Board 

Services, Yorktown Heights, New York, and was funded by Educational Facilities Lobora- 
tories, Inco 



5 



media proJucHon and library services 
a curriculum Improvement center 

educational research programs, specializing In developing units 
of comouter-osslsted Instruction 
data processing 

technic ol/vocatlonal programs in 15 major areas 
In-service education 

administrative services to the 13 districts 



The Information collected on this project simply had to correspond to the client's own admini- 
strative structure (the programs and services I mentioned foil under 6 major odministrative di- 
visions) o This Is not the way the architect will use It at all , Certainly ot one point, for In- 
stance, he cares how "data processing ' will relate to 'vocational education however, he 
will also be interested in how the various parts of data processing relate to the various parts 
of vocational education, and so on and on; after the interrelationships are spelled out, he 
will then be anxious to Investigate each of these parts In detail — translating Its environmen- 



tal Implications Into facility requirements < 



What Is needed for the "bridge" between origin and destination, what we needed on this pro- 



ject, was some sort of tool which would, 

1 • Accept information which Is client-oriented. 

2. Allow the tagging, storage, and retrieval of this Informotlon. 

3. Allow the decomposition of this Information Into vori<Mis levels of 



A. 



detail, and. 

Allow the merging ai;d synthesis of this information at whatever de- 
grees or levels required by the user (the architect, designer, finan- 



cier, or whomever) 



I 

This suggests not only a careful structure, but also some sort of iNiTlAL QUANTUM LEVEL, 



I 
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or BUILDING BLOCK of datOo A quantum which can be further decomposed, but more im- 
portantly, a quantum which can be merged v/ith others o At any point in this FISSION or 
FUSION PROCESS, then, USAGE CRITERIA MAY EMERGE » 

In the project for Northern Westchester, we developed an initial quantum — at least common 
denominotor, if you will — called the activity/space. It seemed to us that in a project this 
complicated, and this activity-oriented, we hod to hit on something which would truly reflect 
vdiot is happening* Since the regional education center is a collection of activities — 
programs and services — this activity-based approach seemed logical , It might be different 
with another project and In another situation . 

Each of the six major administrative areas in the project was broken down Into a series of com- 
ponent activity/spaces. The level of the activity/space, however, is a tricky thing: we know 
that *yata processing" is too large a quantum — it involves many diverse activities with di- 
verse facility implications (machine, discussion, programming, coffee activities)* Yet to 
breok the data processing activities down too far — to seeing, heoring, etco — will not gen- 
erate any coherent facility implications* The initial "level" chosen is somewhere intermediate 
beteraen the two extremes: the activity/space, simply defined, is an "activity which takes up 
space and has a generally common set of facility Implications". 

One of the major "activities" undertaken at the regional center will be guidance and counseling. 

Here the activity/spaces include ones like, 

reception 

lounge and waiting 
coats 

occupational resources 
individual counseling and testing 
group counseling 
group testing 



o 



clerking 
records, etc« 
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You will notice that each of these could be a room or definite building space, but then agoin, 
it could be moie than one room ( "counseling'' might require several), or it could be only port 
of o worn ("clerking” and “records" may have the same use patterns and facility implications, 
allowing accommodation in a single area — or maybe "group counseling" only uses o conference 
type area 50% of the time and could share it with another compotible useX What I am trying to 
say is that it b not yet a space — just an activity which tokes up space. 



The next step is to treat the activity/space like a file drawer in a large filing cabinet (Figure 
2 ^ . We begin to enter the data we hove gathered about the activity: 

what Is it? 

who is involved? do they stay or just come and go? 
who comes and goes and from where? 
whot kinds of material come in and go out? 
what kind of access b involved? directly from reception? 
directly from circulation? insulated from the public? 
to the outdoors? 

how does it relate to other octivlty/spoces? 
what kinds of environmental implications are there “** for 
the visual surroundings? acoustical? mechanical? 
wluit kinds of furniture and equipment are required? 
what special features are involved? 
how much space does the activity consume? 
what may change? 



At this point, too, we can begin to enter data ct levels other than |ust the file drower . Some 
drawers (activity/spaces) moy be tentatively grouped into a file cabinet — and some informa- 
tion entered at the cabinet level — applying to all the draweis. Or within the activity/spoee 
drawer, we may enter data on file “cards" -- eloboiotlorrs on equipment, access, orxl others. 



o 



We did this in the project of which I speak. The next step is a flexible one, depending on the 
demands of the problem. In the case of the regional center with many diverse octivities which 
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should be cross-fertilizing and feeding each other, the inferreiafionship among the activity/ 
spaces W 05 deemed crucial . The next step, therefore, involved using the drawer information 
to expiess functional relationships among the activity/spaces and then to derive, from this dato, 
thf «q|uisite phyrJcal interr^ !ationships» The particular mechanism we chose for this was COM- 
MERCE — the flow of people and material from activity/space to activity/space » We isolated 
8 diffsrent types of commerce, and weighted the flow of each type between each pair of ac- 
tivity/spaces according to the frequency of its flow (Figure 3) ^ 

This in time led us to make a rather subjective stab at the PHYSICAL AFFINITY (or ADJACENCY) 
of one activity/space for onotherp These adjacencies tell how "close" one octlvity/space should 
be to another, and are expressed (in this cose) in such general terms os "direct", "indirect", and 
"convenient" p 

Plotting these affinities begins io give us a look at the project's oigonization — at least from the 
commerce point of view (Figures 4 and ^ c In the Westchester project. It served to verify our 
expectations that the overall building concept would not come from moving bolloom morked 
"data processing" and "guidance center" around on a big booido The "true" orgonization of the 
project in team of Its commerce shows an orgonizotion which bears only a faint resemblance to 
these administrative divisions. 

The next step might involve a restudy of offinities, using some yardstick other than commerce* 

In other words, it mirfit be desirable to reorganize on the idea of grouping all activities requir- 
ing air conditioning, seeing how this modifies the commerce-produced relations* 

Just what the user — and you will note that the clpar distinction between programmer and designer 
seems to hove evaporated — does next Is up to him arxi the demorxls of the situation* The demands 
of the Westchester situation were that we provide sizes, square footoges, etCo far budget and fund- 
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Figure 3s Commerce Pofterre and Adiocencieft for 3 ActWity/SpoC-a. 
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Figure 5; Student Commerce Subty»tem; An Exampla Using 27 Activity/Spacei 
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Figure 4; Di^ct and indirect Adjacencies; An Es^ample Using 27 Acrtvity/Sno c^ 



9 



raising purposes o So we begem to translate the octivity/spaces into building spaces. As sug- 
gested before, some merged with others, some generated one building space, others many 
building spaces, and still others only portions of building spaces o When an activity only re- 
quired a particular kind of space on a part-time basis, the tool allowed us to search for com- 
parable activities for the same space. 

The next step in our effort involves reorganization and re-expresslon of the data base to serve 
many of the other ends in programming and programming/design. It is hoped that the project 
staffxan carefully monitor the architect as he uses end manipulates the date base , This will 
give us further directions for modifying the approach and for designing the actual "tool** (most 
likely a series of computer programs) for performing the manipulotions. 



I will be the fi«st to admit that the process was pretty crude in our Westchester application. 

We did the job by hand — there were, for instance, 166 of those activity/spaces, which meons 
there were some 13,000 potential affinities in the projects We were subjective, intuitive, and 

inconsistent. 

The point it thU, howavers we do thiric we found o tool which tet up o doto b«so - oriented to 
getting infonnotion in, manipulating and massaging it, and then to getting criteria out os needed 
by the architect. We used dt.j processing techniques only for the most clerical of losla,-- Ihh 
was all time and fonds allowed — but an on-line computer system is clearly in view. The Intro- 
duction of the computer in a conversational capacity ~ constantly retrieving, displaying, and 
manipulating the data base under the user's direction ~ would bring coherency and consistan^ 
fo the process of data manipulation and criteria formulation. 

Of couise, file drawer approaches are hardly new- But a dynamic filing system, allowing both 
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fisiion and fusion of chunks of data ta produce design criteria, will be entirely necessary as 
projects become more complex and as programming dota multiplies* Under constant control 
of the user, it will hopefully allow adaptation to varying situations, and will help to eradi- 
cate the often arbitrary division between programming and design * 

Nor are such approaches without theirdangers and pltlbl Is* Weoll know thot systematic approoches, 
if not carefully' controlled, con masticate and destroy data* We oil know that there are dongen 
of "hardening of the categories"* We ail know that the user moy be a victim of false precision, 
or he may suffer from delusions of accuracy* 

For all 1 know, this happened to us on the Watehester project — the faults won't be in until 
the orchiteet begins working with the requirements a detailed in our "program" > So for, though, 
we feel that the need to do something ha been worth the risks* 



